Columbia Kermit/kermit.zip/e/misc.save/[e-mail]_Fri Dec 14 12:39:43 2007.msg

Internet Message Format | 2020-01-01 | 4KB

Path: reader1.panix.com!panix!newsfeed.stanford.edu!sn-xt-sjc-02!sn-xt-sjc-09!sn-post-sjc-01!supernews.com!corp.supernews.com!not-for-mail
From: [e-mail] (Robert Bonomi)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Screen Capture
Date: Thu, 13 Dec 2007 23:25:04 -0000
Organization: Widgets, Inc.
Message-ID: <[e-mail]>
References: <h654j.66697$[e-mail]> <[e-mail]> <g3J7j.77732$[e-mail]>
X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
Originator: [e-mail] (Robert Bonomi)
X-Complaints-To: [e-mail]
Lines: 62
Xref: panix comp.protocols.kermit.misc:15716

In article <g3J7j.77732$[e-mail]>,
2damn  <[e-mail]> wrote:
>On Mon, 03 Dec 2007 03:47:21 +0000, Robert Bonomi wrote:
>
>> In article <h654j.66697$[e-mail]>, 2damn
>> <[e-mail]> wrote:
>> Kermit has the 'log' command that will provide various kinds of gory
>> detail to a file.  'log session' before a 'connect' command, and you wil
>>  capture all the interactive stuff you do, and which you can use to
>> built a script from.
>>
>>
>> This approach fails if the remote system thinks its talking to something
>> where it can play cursor-positioning and selective over-write games.
>>
>> If you can tell the remote computer that you're using some kind of a
>> 'dumb' hard-copy terminal this issue is moot.
>>
>> Else, screen-scraping gets *VERY* complex.
>
>I tried "log" and it does contain communication data that is not useful
>for me. And some bits are total garbage so there may be some of what you
>mention in your second paragraph going on.
>
>I have found that "cat /dev/vcsX" can copy ttyX, but of course not my
>ttySX. I can format the capture with newlines (dd) and trim what I want
>(sed). Attempting to get it to work on the serial lines.


OK, bluntly, given your descriptions, _you_ cannot get C-Kermit to do that
which you want to happen.

Building application-specific 'screen-scraping' logic in Kermit macro-language
*is* possible, but *very* _painful_, and works only for the exact screen
form for which it was coded.  If _anything_ changes regarding how the remote
machine generates the screen, the  macro programming requires major reworking.

Developing such macros requires an *intimate*knowledge* of what the remote
machine is doing, and what kind of device it 'thinks' it is talking to, *AND*
the gory details of the formatting/addressing protocol(s) being used.  And if
the remote machine's concept of the terminal device can be changed or not.
Also, if it can be changed, what are _all_ the possible alternatives.

As you apparently lack this essential information about the environment you
are trying to work in, and don't have the experience to simply 'recognize on
sight' the protocol data in what you have described as the 'total garbage',
you do not have the required skill-set to build the solution you need.
(This _is_ "specialist" knowledge/skills -- unless you routinely do work
involving 'faking a terminal', it's not surprising that you don't know these
things -- they're *not* part of the 'general skills'. )

Your best bet is to hire a knowledgeable professional -- one _with_ expertise
in 'serial port communications' -- for (A) a consultation on 'what is
going on' in your specific situation, (B) 'what is practical' as regards
EXACTLY what you are trying to accomplish, and then, possibly (C) development
of custom software -- probably not based on Kermit -- to solve your problem.


Feel free to e-mail me directly with further questions.  Please start the
subject line with 'KERMIT', so I'll see it.